bitrepository-reference

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Nej, det har du helt ret i. Skal nok lige have fjernet PillraTestGroups.CHECKSUM_PILLAR_TEST fra test annoteringen ovenfor.

Nej, det har du helt ret i. Skal nok lige have fjernet PillraTestGroups.CHECKSUM_PILLAR_TEST fra test annoteringen ovenfor.

Dette kommer vel ikke til at virke med ChecksumPillar? Den kan da ikke håndtere salt - med mindre det er default

Dette kommer vel ikke til at virke med ChecksumPillar?
Den kan da ikke håndtere salt - med mindre det er default

Ja.. og godt det bliver spottet

Ja.. og godt det bliver spottet

copy-paste?

copy-paste?

ReplaceFileDestination ??

ReplaceFileDestination ??

Bump jetty-server in /bitrepository-core

Bumps [jetty-server](https://github.com/eclipse/jetty.project) from 8.1.5.v20120716 to 9.4.17.v20190418.

- [Release notes](https://github.com/eclipse/jetty.project/releases)

- [Commits](https://github.com/eclipse/jetty.project/compare/jetty-8.1.5.v20120716...jetty-9.4.17.v20190418)

Signed-off-by: dependabot[bot] <support@github.com>

Make sure that target folder exists when running pillartests, otherwise jaccept may fail to generate report

Add initial integration tests for DeleteFile functionality
Add initial integration tests for DeleteFile functionality
Exit script with last commands return code

Don't always exit 0, use test process's exitcode

Specify url to file

Upload default file as part of integration test

Add runpillartests.sh and runperformancetest.sh so that acceptence pillar tests are functional

    • -0
    • +34
    /bitrepository-reference-pillar/src/test/bin/runperformancetest.sh
    • -0
    • +39
    /bitrepository-reference-pillar/src/test/bin/runpillartest.sh
The method is used quite rarely, but when it is called, then it is mostly called several times in a row. How about caching them the first time this method is called?

The method is used quite rarely, but when it is called, then it is mostly called several times in a row.
How about caching them the first time this method is called?

Agreed, and added it with the default value, along with a couple of other missing settings.

Agreed, and added it with the default value, along with a couple of other missing settings.

Should we get these info dynamically, or should we cache them when the HadoopFileInfo object is made?

Should we get these info dynamically, or should we cache them when the HadoopFileInfo object is made?

This should probably also list a implementing class for the pillar

This should probably also list a implementing class for the pillar

Probably. These files let's the pillar connect to the narcana cluster.

Probably. These files let's the pillar connect to the narcana cluster.

Done

Done

Jeg er ret sikker på at Asger Askov Blekinge kan sætte det op (vil tro det kræver administrator adgang til nexus)

Jeg er ret sikker på at Asger Askov Blekinge kan sætte det op (vil tro det kræver administrator adgang til nexus)

The public methods need argument validations

The public methods need argument validations

needs argument validation

needs argument validation

Yeah, that would be better. How can it be done?

Yeah, that would be better. How can it be done?

Is it not possible to have this mirrored through sbforge repo?

Is it not possible to have this mirrored through sbforge repo?

I suppose the file is not actually used to connect to a hadoop cluster, but rather to verify that it can be properly loaded. In such case this file along with the corresponding hdfs-site.xml file s...

I suppose the file is not actually used to connect to a hadoop cluster, but rather to verify that it can be properly loaded.
In such case this file along with the corresponding hdfs-site.xml file should have hosts changed to dummy content (just like RepositorySettings.xml which lies next to this file)