Techognito/starter-kit
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
211 commits 2 branches 0 tags 2.9 MiB
Find a file
Martin Pitt 2a51e057d7 Show how to run the release in GitHub workflow 
Enter the new world of GitHub actions [1]/GitLab pipelines [2]. This
simplifies our end of the infrastructure considerably:

* No need any more to set up webhooks, all the relevant configuration
  is right in the workflow file.

* Does not need any infrastructure on our side any more, and thus works
  for third-party projects. They just need to set up their own secrets.

* GitHub automatically provides a temporary `GITHUB_TOKEN` with
  sufficient write access to the project to publish a release, so we
  don't need to carry around that secret. Thus if your project only
  releases to GitHub, there is zero secrets management.

Also adjust cockpituous-release a bit (update Fedora version, fix
project name copy-pasta), point to the action workflow and necessary
secrets.

Closes #380
2020-10-13 09:37:35 +02:00
.github/workflows Show how to run the release in GitHub workflow 2020-10-13 09:37:35 +02:00
po Fix building PO template 2020-09-29 13:50:31 +03:00
src Use standard "translate" marker in HTML 2020-09-29 13:50:31 +03:00
test Port to PatternFly 4.x 2020-07-21 10:33:48 +02:00
.eslintignore Add more sample content to subscriptions page 2017-07-26 10:33:14 +02:00
.eslintrc.json Add eslint rules for React hooks 2019-10-18 13:00:17 +02:00
.gitignore Copy patternfly import files from cockpit project automatically 2020-09-08 17:14:34 +02:00
.tasks tasks: Drop issue-scan 2019-07-11 11:58:18 +02:00
.travis.yml Fix building PO template 2020-09-29 13:50:31 +03:00
cockpit-starter-kit.spec.in Make cockpit-starter-kit.spec.in rpmspec compliant 2020-03-10 11:49:29 +01:00
cockpituous-release Show how to run the release in GitHub workflow 2020-10-13 09:37:35 +02:00
LICENSE Initial commit with a LICENSE and README 2017-06-14 18:19:15 +02:00
Makefile npm: Upgrade webpack related development dependencies 2020-09-28 07:49:01 +02:00
org.cockpit-project.starter-kit.metainfo.xml metainfo: Fix launchable and update description 2020-08-05 13:45:57 +02:00
package.json package.json: Update @patternfly/react-core package dependency 2020-10-09 22:30:48 +02:00
README.md Show how to run the release in GitHub workflow 2020-10-13 09:37:35 +02:00
webpack.config.js npm: Upgrade webpack related development dependencies 2020-09-28 07:49:01 +02:00

README.md

Cockpit Starter Kit

Scaffolding for a Cockpit module.

Getting and building the source

Make sure you have npm available (usually from your distribution package). These commands check out the source and build it into the dist/ directory:

git clone https://github.com/cockpit-project/starter-kit.git
cd starter-kit
make

Installing

make install compiles and installs the package in /usr/share/cockpit/. The convenience targets srpm and rpm build the source and binary rpms, respectively. Both of these make use of the dist-gzip target, which is used to generate the distribution tarball. In production mode, source files are automatically minified and compressed. Set NODE_ENV=production if you want to duplicate this behavior.

For development, you usually want to run your module straight out of the git tree. To do that, link that to the location were cockpit-bridge looks for packages:

mkdir -p ~/.local/share/cockpit
ln -s `pwd`/dist ~/.local/share/cockpit/starter-kit

After changing the code and running make again, reload the Cockpit page in your browser.

You can also use watch mode to automatically update the webpack on every code change with

$ npm run watch

or

$ make watch

Running eslint

Cockpit Starter Kit uses ESLint to automatically check JavaScript code style in .js and .jsx files.

The linter is executed within every build as a webpack preloader.

For developer convenience, the ESLint can be started explicitly by:

$ npm run eslint

Violations of some rules can be fixed automatically by:

$ npm run eslint:fix

Rules configuration can be found in the .eslintrc.json file.

Automated Testing

Run make check to build an RPM, install it into a standard Cockpit test VM (centos-7 by default), and run the test/check-application integration test on it. This uses Cockpit's Chrome DevTools Protocol based browser tests, through a Python API abstraction. Note that this API is not guaranteed to be stable, so if you run into failures and don't want to adjust tests, consider checking out Cockpit's test/common from a tag instead of master (see the test/common target in Makefile).

After the test VM is prepared, you can manually run the test without rebuilding the VM, possibly with extra options for tracing and halting on test failures (for interactive debugging):

TEST_OS=centos-7 test/check-application -tvs

You can also run the test against a different Cockpit image, for example:

TEST_OS=fedora-32 make check

Customizing

After cloning the Starter Kit you should rename the files, package names, and labels to your own project's name. Use these commands to find out what to change:

find -iname '*starter*'
git grep -i starter

Automated release

Once your cloned project is ready for a release, you should consider automating that. Cockpituous release aims to fully automate project releases to GitHub, Fedora, Ubuntu, COPR, Docker Hub, and other places. The intention is that the only manual step for releasing a project is to create a signed tag for the version number; pushing the tag then triggers a GitHub action that calls a set of release scripts.

starter-kit includes an example cockpitous release script, with detailed comments how to use it. There is also an example GitHub release action to set up secrets and run cockpituous.

Further reading