Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom release assets #155

Open
bennypowers opened this issue Mar 2, 2022 · 9 comments · May be fixed by #347
Open

Custom release assets #155

bennypowers opened this issue Mar 2, 2022 · 9 comments · May be fixed by #347

Comments

@bennypowers
Copy link

I'd like to bundle my monorepo into a single file whenever I release and upload that as a release asset

I can do that with github actions and the github rest api, but I'd rather have changesets do that in the changesets action. It would be nice to have a hook to run my own custom build process for releases

@Andarist
Copy link
Member

Andarist commented Mar 2, 2022

I'd like to bundle my monorepo into a single file

Could you describe this in more detail? I'd like to understand the context behind the feature request better.

It would be nice to have a hook to run my own custom build process for releases

Could you roughly describe how this would work? Additional question - can assets be attached after the release is already published?

@bennypowers
Copy link
Author

Thank you @Andarist for the reply. Allow me to elaborate:

I am participating in the development of a design system, implemented in an npm monorepo of ~20 web components. Under normal circumstances, users would load whichever components they needed via a module transforming CDN (e.g. unpkg) or with import maps (e.g. jspm), or by npm installing and bundling themselves.

However, many of our users do not want to have to install a node/npm toolchain in order to fetch and bundle our components, and they are prevented by compliance concerns from using third party CDNs like unpkg or jspm

Therefore, we'd like to provide a complete single-file bundle of our design system so that users can download a single javascript file and use it however they like.


Now, from what I gather, I can set up a workflow which bundles the monorepo and uploads it as an asset to an existing release

name: Bundle

on: 
  release: 
    types:
      - published

jobs:
  bundle:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 16
          cache: npm

      - run: npm i --prefer-offline
      - run: npm run build
      # outputs to /releases/$GITHUB_REF/bundle.min.js
      - run: node scripts/bundle-release.js 
      - uses: actions/github-script@v6
        with:
          script: |
            // yadda yadda
            github.rest.repos.uploadReleaseAsset({
              owner,
              repo,
              release_id,
              name,
              data,
            });

I think the downside to this would be the delay in between creating the release and uploading the asset

Instead, perhaps there could be some assets param to changesets action which looks for assets in a newline-separated string of filenames and attaches them if present

name: Release

on:
  push:
    branches:
      - main
      - master

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 16
          cache: npm

      - run: npm i --prefer-offline
      - run: npm run build

      - name: Create Release Pull Request or Publish to npm
        uses: changesets/action@v1
        with:
          publish: npx changeset publish
          commit: "chore: version packages"
          # files are uploaded as-is,
          # directories get tarballed then uploaded
          # changesets action could also automatically upload the npm package tarballs
          assets: |
            /releases/${{ env.GITHUB_REF }}/bundle.min.js
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

@bennypowers
Copy link
Author

An important point I missed in yesterday's comment: the config I proposed there (assets key) would not work as shown, since the build process would need to know about the release's metadata via the env

@bennypowers
Copy link
Author

Alternatively, if changesets/action would provide the release ID as an output, users could easily modify the release after publish:

      - name: Create Release Pull Request or Publish to npm
        uses: changesets/action@v1
        id: changesets-release
        with:
          publish: npx changeset publish
          commit: "chore: version packages"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
      - name: Upload Release Asset
        id: upload-release-asset 
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.changesets-release.outputs.release-url }}/upload
          asset_path: ./releases/${{env.GITHUB_REF }}/bundle.min.zip
          asset_name: bundle.min.zip
          asset_content_type: application/zip

@mark-omarov
Copy link
Contributor

Since changesets support monorepo and we can have several different packages released, a singular assets config might not work very well.

If changesets/action would also include release ID in the outputs.publishedPackages for every published/released item, that would help, or perhaps something similar but solely focused on outputting only for released packages.

I'm facing this issue with non-npm packages (applications), and as a workaround I'm going to use whatever is available in the outputs.publishedPackages to craft the lookup tag, then retrieve the release, using the upload URL for every release I'd then compile applications and upload to respected assets. Not ideal, but better than nothing.

It'd be greater if changesets/action could do the heavy lifting though.

@irshadahmad21
Copy link

If #347 is accepted, then we should be able to upload assets to the releases.

@zanminkian
Copy link

I'm facing the same problem and I need this feature too. Any progress?

@MrSquaare
Copy link

@Andarist could you please take a look at the proposed PR?

@cumt-robin
Copy link

This is a very meaningful feature to look forward to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants