Workflows for automated releases and github-pages builds #3137

alexcottner · 2024-01-22T20:20:04Z

Example links

GitHub Pages Deployment
This will happen automatically upon release publish, or manually whenever a user wants to create a demo build for user acceptance testing. Added notes in readme.md for fork repo configuration and notes on the actions.

Automatic Release Creation on Tags
When a tag is created that matches the v{major}.{minor}.{build} pattern, this workflow will:

Create a new release draft if a release doesn't already exist. This does not fill out any release notes.
Build and publish a single-server build on the release that kinto CD pipelines or users can download

Open Questions

Is creating a draft release for us to fill out good enough? Or do we want to try and prefill some release notes content?

Misc
Commits will be squashed on merge to make this clean.

…context on github

leplatrem

This workflow differs slightly from what we have in other repos:

Create a release on Github on https://github.com/Kinto/kinto-admin/releases/new
Create a new tag vX.Y.Z (This tag will be created from the target when you publish this release.)
Generate release notes
Publish release

If possible it would be better to align it with the rest. As far as I understand, it only means making sure the release.yml workflow does not try to create the release when it already exists, and would just add attachments.

Also, I think we may want to deploy official versions on Github pages automatically.

README.md

leplatrem · 2024-01-24T12:17:32Z

README.md

+5. Publish the release when ready
+
+## Deploying to github-pages
+A github workflow is included that will release to github pages for any user acceptence testing you may want to do. You must enable github pages first and allow deployment from github actions (Settings > Pages).


Don't we want to deploy to Github pages automatically on tags?

You must enable github pages first and allow deployment from github actions

What does it mean? Approve deployments?

leplatrem · 2024-01-24T12:18:19Z

README.md

+## Deploying to github-pages
+A github workflow is included that will release to github pages for any user acceptence testing you may want to do. You must enable github pages first and allow deployment from github actions (Settings > Pages).
+
+By default, most branches are restricted from deploying. Additional branches can be allowed to deploy (or any can be allowed) under Settings > Environments > github-pages.


I think it would be clearer with two parts:

automated deployment on release (along with the releasing info)

how to deploy custom branch on gh-pages

Tried to make all of this a little clearer. Will read it again tomorrow to see if it still makes sense though.

.github/workflows/gh-page.yml

.github/workflows/release.yml

Co-authored-by: Mathieu Leplatre <mathieu@leplat.re>

alexcottner · 2024-01-24T21:41:50Z

Also, I think we may want to deploy official versions on Github pages automatically.

Seems like there are two easy ways to make that happen, which sounds better to you?

Kick off gh-pages.yml after release.yml runs
Have gh-pages.yml also listen for tag creation

grahamalama · 2024-01-25T15:49:54Z

Have gh-pages.yml also listen for tag creation

I vote this one 👍🏻

leplatrem

Seems like there are two easy ways to make that happen, which sounds better to you?

Kick off gh-pages.yml after release.yml runs

Have gh-pages.yml also listen for tag creation

I would vote for 2. But no strong opinion.

leplatrem · 2024-01-25T15:21:24Z

.github/workflows/release.yml

+            cd build
+            tar -cvf "$RUNNER_TEMP/kinto-admin-release.tar" *


nit

Suggested change

cd build

tar -cvf "$RUNNER_TEMP/kinto-admin-release.tar" *

tar -cvf --cd build/ "$RUNNER_TEMP/kinto-admin-release.tar" *

I don't have --cd as a valid option on my machine or on the ubuntu 22.04 docker container I just pulled. And I don't see it in the manual. Is this some non-standard thing or am I totally overlooking it?

OOps https://www.gnu.org/software/tar/manual/html_node/directory.html

README.md

leplatrem · 2024-01-25T17:45:45Z

README.md

+    2. Under "Build and deployment" choose Source > GitHub Actions
+2. Choose which branches should be allowed to deploy to pages
+    1. Go Settings > Environments > Github Pages
+    2. Under "Deployment branches and tags", configure which branches should be allowed to deploy to pages


There's something that I find unclear in these instructions...
Are they meant to be ran each time? Are they targeted at contributors/forks?

Trying to make that clearer

leplatrem · 2024-01-25T17:46:04Z

README.md

+2. Select the "Deploy to Github Pages" action
+3. Select "Run workflow" and choose the branch you wish to build against
+4. Click "Run workflow"
+5. Kinto-admin will be deployed to `https://{owner}.github.io/kinto-admin`


Why {owner} here?

{owner} is the syntax I've seen in the github docs. So the for kinto's repo this would be https://kinto.github.io/kinto-admin, but for my fork it's https://alexcottner.github.io/kinto-admin/ . Is there a way to make this clearer?

alexcottner · 2024-01-25T19:48:56Z

gh-pages workflow listens for release publishes and will publish a build to pages automatically.
Updated readme to be clearer

grahamalama · 2024-01-25T19:33:56Z

README.md

+2. When tagging your release, enter a standard version number like `vX.Y.Z`
+3. After the release is published (including pre-release), built assets will be attached as files, including:
+    1. Source code based on the tagged commit
+    2. A single-server build for kinto-admin in a tar file (this may take a few minutes to show up)


Suggested change

2. A single-server build for kinto-admin in a tar file (this may take a few minutes to show up)

2. A single-server build meant to be used in a `kinto` installation in a tar file (this may take a few minutes to show up)

Do you think we should explicitly mention that we're setting ASSET_PATH and SINGLE_SERVER?

Being verbose can't hurt. Will add.

grahamalama · 2024-01-25T20:11:30Z

.github/workflows/release.yml

+            LATEST_TAG=$(echo $GITHUB_REF | sed s/^v// | tr -d '"')
+            VERSION_NUMBER=".version=\"${LATEST_TAG}\""
+            jq ${VERSION_NUMBER} package.json > temp_package.json
+            mv temp_package.json package.json


One issue with doing this only in CI is that if people build Kinto Admin the "old" way to customize build variables (that is, curl the source code then run npm run build), the version won't be overwritten.

What if we handled this in vite.config.ts instead? Here's a quick example that only gets the latest tag, but perhaps we could write a function that encompases all of the logic currently in the action workflow:

diff --git a/vite.config.ts b/vite.config.ts index 9817bd7..f2d2111 100644 --- a/vite.config.ts +++ b/vite.config.ts @@ -2,6 +2,8 @@ import { defineConfig } from 'vite' import react from '@vitejs/plugin-react' +import { execSync } from 'child_process' + /** * used to set the relative path from which we expect to serve the admin's * static bundle on the server: @@ -9,7 +11,7 @@ import react from '@vitejs/plugin-react' * Kinto plugin: /v1/admin/ */ const ASSET_PATH = process.env.ASSET_PATH || "/"; - +const KINTO_ADMIN_VERSION = execSync('git describe --tags --abbrev=0').toString() // https://vitejs.dev/config/ export default defineConfig({ server: { @@ -19,7 +21,7 @@ export default defineConfig({ plugins: [react()], base: ASSET_PATH, define: { - KINTO_ADMIN_VERSION: JSON.stringify(process.env.npm_package_version), + KINTO_ADMIN_VERSION: JSON.stringify(KINTO_ADMIN_VERSION) }, build: { outDir: "build"

I do like that this simplifies things. I'll combine this with @leplatrem 's suggestion above to do a --abbrev=4. If they're exactly on a tag, it'll just be the tag name returned. If they're beyond that tag, it'll note how far ahead they are and which sha they're on.

Implemented!

grahamalama · 2024-01-26T00:58:28Z

.github/workflows/release.yml

+      - name: Create release
+        uses: softprops/action-gh-release@v1
+        with:
+          draft: true
+          fail_on_unmatched_files: true
+          files: ${{ runner.temp }}/kinto-admin-release.tar


This seems like it works just fine, so consider this comment optional, but it might be nice if we don't have to rely on a 3rd party action for this. It looks like the gh CLI has a release command built in -- maybe that'd work?

I settled on this one after finding actions/create-release being archived/unsupported and it's read-me mentioning this one and it seeming simple enough for our needs.

I'll look into the cli option to see what that takes.

Implemented!

leplatrem

💯 The ghpages section in the docs is a lot clearer with these titles , thanks for your patience 🙏

grahamalama

Looks good! Does this also mean we can rip out the publish-to-gh-pages command and gh-pages dependency?

alexcottner · 2024-01-26T17:12:25Z

Does this also mean we can rip out the publish-to-gh-pages command and gh-pages dependency?

Oh yes, I'll do that. I forgot to remove those because my plan A was to use them, but that didn't work out.

alexcottner and others added 19 commits January 22, 2024 13:18

Working on github pages workflow

61e5f83

removed on manual placeholder

88b21e1

adding on workflow_dispatch

b8718eb

fixing yaml

096144c

adjusting yaml again

cfaeff4

removed cross-env reference

c8d87b0

copying git user name and email from last commit

95552af

inspecting git username and email

7723aa3

Switching to use github pages actions

b267bf9

fixing indent

cb0a34c

trying to fix workflow...

69267c6

More tweaks

fe811b3

Switching to upload-pages-artifact

3166143

changing path

27943a2

fixing asset path

72fbc30

updated readme to include github-pages deployment notes

6a5594d

Merge branch 'Kinto:master' into master

ec0b55a

Merge branch 'github-build'

476ef39

Working on release creation on tag

096b7eb

alexcottner changed the title ~~Working on github pages workflow~~ Workflows for automated releases and github-pages builds Jan 23, 2024

alexcottner added 2 commits January 23, 2024 10:06

adding tags fetch before checking latest tag

53d6fa7

Removing tag from gh-page version since we don't appear to have that …

28e6474

…context on github

alexcottner requested review from leplatrem and grahamalama January 23, 2024 17:49

alexcottner marked this pull request as ready for review January 23, 2024 17:50

updated readme for releasing

68db91e

leplatrem reviewed Jan 24, 2024

View reviewed changes

alexcottner and others added 3 commits January 24, 2024 14:10

Update README.md to be more clear on publishing to gh pages

ab6441f

Co-authored-by: Mathieu Leplatre <mathieu@leplat.re>

updating readme with more release info

8e0ea56

renamed gh-page to gh-pages

4b62cdb

alexcottner added 2 commits January 24, 2024 14:26

simplifying sed

f8505a4

Fleshed out deploying to github pages section in readme

9e016b9

leplatrem reviewed Jan 25, 2024

View reviewed changes

alexcottner added 5 commits January 25, 2024 12:14

Working on gh-pages updates

29586d3

switching to ref_name

7ff878e

ref and ref_name are empty?

3581254

fixed version number for pages release on tag

137f8f2

fixing GITHUB_REF var

f707899

grahamalama reviewed Jan 25, 2024

View reviewed changes

alexcottner added 4 commits January 25, 2024 13:48

Changing version number string based on feedback

343aa60

Making single-server build notes more detailed

e6b6c03

simplifying version number setting

dd08c2b

need to add fetch-depth for all actions/checkouts

0c6435c

grahamalama reviewed Jan 26, 2024

View reviewed changes

alexcottner added 4 commits January 26, 2024 09:01

Removing 3rd party action

1f8a086

fixed var name

83f9e67

Added gh token

b809d8f

consuming error

5345ee2

leplatrem approved these changes Jan 26, 2024

View reviewed changes

grahamalama approved these changes Jan 26, 2024

View reviewed changes

alexcottner and others added 3 commits January 26, 2024 10:13

Removed gh-pages dependency

719c9e3

Merge branch 'Kinto:master' into master

4107f98

fixing merge conflict

e3ffc89

alexcottner merged commit 2d2b28b into Kinto:master Jan 26, 2024
6 checks passed

alexcottner deleted the github-build branch January 26, 2024 17:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Workflows for automated releases and github-pages builds #3137

Workflows for automated releases and github-pages builds #3137

alexcottner commented Jan 22, 2024 •

edited

Loading

leplatrem left a comment •

edited

Loading

leplatrem Jan 24, 2024

leplatrem Jan 24, 2024

alexcottner Jan 24, 2024

alexcottner commented Jan 24, 2024

grahamalama commented Jan 25, 2024 •

edited

Loading

leplatrem left a comment

leplatrem Jan 25, 2024

alexcottner Jan 25, 2024

leplatrem Jan 26, 2024

leplatrem Jan 25, 2024

alexcottner Jan 25, 2024

leplatrem Jan 25, 2024

alexcottner Jan 25, 2024

alexcottner commented Jan 25, 2024

grahamalama Jan 25, 2024

alexcottner Jan 25, 2024

grahamalama Jan 25, 2024

alexcottner Jan 25, 2024

alexcottner Jan 25, 2024

grahamalama Jan 26, 2024

alexcottner Jan 26, 2024

alexcottner Jan 26, 2024

leplatrem left a comment

grahamalama left a comment

alexcottner commented Jan 26, 2024

	cd build
	tar -cvf "$RUNNER_TEMP/kinto-admin-release.tar" *
	tar -cvf --cd build/ "$RUNNER_TEMP/kinto-admin-release.tar" *

	2. A single-server build for kinto-admin in a tar file (this may take a few minutes to show up)
	2. A single-server build meant to be used in a `kinto` installation in a tar file (this may take a few minutes to show up)

Workflows for automated releases and github-pages builds #3137

Workflows for automated releases and github-pages builds #3137

Conversation

alexcottner commented Jan 22, 2024 • edited Loading

leplatrem left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcottner commented Jan 24, 2024

grahamalama commented Jan 25, 2024 • edited Loading

leplatrem left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alexcottner commented Jan 25, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

leplatrem left a comment

Choose a reason for hiding this comment

grahamalama left a comment

Choose a reason for hiding this comment

alexcottner commented Jan 26, 2024

alexcottner commented Jan 22, 2024 •

edited

Loading

leplatrem left a comment •

edited

Loading

grahamalama commented Jan 25, 2024 •

edited

Loading